The present invention relates in general to computer graphics, and in particular to the use of compression in texture mapping functions.
Many computer generated scenes are created by modeling objects in the scene as a three-dimensional representation made of polygons defined by sets of vertices. Various types of texture maps may then be applied to the polygons to create a desired (e.g., realistic) look and feel for the scene. Application of the textures may include applying texture coordinates to polygon vertices, subdividing polygons, etc.
For example, a player approaches a brick wall in a video game. The brick wall may be modeled as a set of polygons (e.g., a rectangular prism), and may be rendered in one scene image substantially as a single flat face (e.g., as few as one polygon) visible from the context of the player. Multiple texture maps may then be applied to the face of the wall to make it look like brick. One texture map may include a brick image that is applied as a single image, as tiles, as patches, etc., for example, to provide color effects for the wall. Another texture map may include a normal map, or bump map, for example, to provide depth and lighting effects for the wall.
In graphics processing systems, the rendering method is often divided between a computer's general-purpose central processing unit (CPU) and a graphics processing unit (GPU). Typically, the CPU performs high-level operations, such as determining the position, motion, and collision of objects in a given scene, and generates a set of rendering commands and data defining the desired rendered scene. Rendering commands and data can define scene geometry by reference to groups of vertices, each having attributes, such as texture-map coordinates. The rendering commands and data may then be sent to the GPU for rendering the scene, for example, for viewing on a display.
Over time, suppliers and consumers have desired scene renderings with ever-increasing texture resolutions, thereby placing ever-increasing demands on graphics processing systems. Various types of compression are used with texture maps to allow the graphics processing systems to effectively render scenes having highly complex textures (e.g., large numbers of texture maps, high texture resolutions, high numbers of vertices, etc.). Many of these texture compression techniques, however, have drawbacks.
FIG. 1A illustrates a flow diagram 100 of a prior art texture compression technique. The technique shown in FIG. 1A is illustrative of techniques, like S3 Texture Compression (S3TC), or DXT compression. A texture map 110 is represented as a two-dimensional image. The texture map 110 is partitioned into blocks 115 (e.g., 4-by-4 texture pixel (texel) blocks). Block 115a illustrates a block location in the texture map 110, and block 115b illustrates a zoomed-in view of the same location in the texture map 110. Notably, as illustrated by block 115b, some texels within the block 115 are lighter, while other texels in the block 115 are darker.
Each block 115 is compressed according to the compression technique. As illustrated, the result may be a compressed version of the sixteen-texel (4-by-4) block 115 in eight bytes. For example, two colors may be selected to most closely represent the texels in the block 115. A compressed dataset 120 is generated for the block 115. The compressed dataset 120 includes a first two bytes 120a designating the first color (color0), a second two bytes 120b designating the second color (color1), and four bytes 120c designating sixteen color indices associated with the sixteen texels in the block 115.
The compressed dataset 120 may be sent from the CPU to the GPU when needed for rendering a scene. The GPU may then decompress each block 115 of the texture map 110 by applying the color designations to the texels in the block 115 as indicated by the color indices to generate a decompressed block 130. It is worth noting that the original sixteen texels are recreated by the GPU in a “lossy” manner. It is further worth noting that the technique illustrated in FIG. 1A uses a fixed compression ratio (e.g., DXT1 has a fixed compression ratio of 6-to-1). The fixed compression ratio may decrease the complexity of implementing the technique in hardware, and, indeed, many CPUs on the market are designed to implement DXT compression in hardware.
While DXT and other fixed-rate compression techniques may be compatible with many GPUs, they may not provide sufficient compression for effectively using high-resolution textures in certain applications. As such, other techniques may be used, for example, involving intermediate, variable-rate, high-compression of the texture map. FIG. 1B illustrates a flow diagram 150 of another prior art texture compression technique. The texture map 160 is compressed into a variable-rate, high-compression format, like a JPEG file 170. The compressed JPEG file 170 may be stored as part of the application (e.g., the video game). To use the compressed JPEG file 170, the CPU may have to convert the file to a format compatible with the GPU. Typically, the CPU may decompress the JPEG file 170 into an intermediate decompressed format, like an RGB(A) file 180. The RGB(A) file 180 may then be re-compressed into the compatible format, like a DXT file 190, for GPU rendering. It is worth noting that the technique illustrated in FIG. 1B may yield significantly higher compression ratios than those of the technique illustrated in FIG. 1A. However, the cost of the higher compression ratio includes the extra processing resources (e.g., processing time) used in decompressing and re-compressing the texture map data.
It may therefore be desirable to implement texture compression with high compression ratios and low decompression times.